Much attention has been given to the issue of computer security in recent years. Many efforts for improving computer security have been direct toward software protection and combating software threats such as viruses, “Trojan horse” attacks and other malicious software attacks. Several solutions have been put forth to deal with software protection such as the concept of “trusted software” and to obtain “software integrity” to ensure reliable systems that operate under an established security policy for the system. “Trusted software” relates to the idea of ensuring that the installed software can be trusted by the customer and was free from tampering by unauthorized persons. Major efforts have been directed into developing software security products designed to deal with viruses and malicious software that can infect computer systems.
Although many software security products do effectively detect, prevent, and remove viruses, they do so while running on top of the operating system (OS) and confidence that the security is maintained depends on whether it can be reasonably established that the OS has not been compromised during the bootstrap phase. Patents such as U.S. Pat. No. 6,185,678 describe methods to provide a secure bootstrap process where the integrity of the bootstrap process is ensured by the architecture that initializes a computer system using public key cryptography. However, the emphasis on the software security at this level occurs after the device has been constructed and presupposes that it was delivered to the customer with trusted software and that security has was not breached at any time during the production process. This means that during the manufacturing stage the integrity of the production and distribution supply chain is vitally important, especially when there may be several independent entities involved in the production chain.
Computer systems and many consumer electronics products are typically delivered with preinstalled operating software on the system making them operable right out-of-the-box. However, it is sometimes the case that software revisions and upgrades are developed during the production process by a separate design team located in another country that has a contractual outsourcing relationship with the manufacturer. These outsourcing relationships are often established for cost reasons where manufacturing occurs in lower cost labor markets. The issue of security and software integrity becomes an important issue to the manufacturer when there are several players in the supply chain. An example is where a first company having a software-based application that provides functionality to common computer hardware as its chief product such as a video gaming console or PBX product running on a standard PC-platform. The software may be developed by the developer in a first country and then sent to second company in a second country for manufacturing and assembly. In such an arrangement, it becomes vitally important to the software developer that firstly; they can guarantee that the integrity of the software i.e. no malicious code was injected during the manufacturing process, and secondly the software, which is their high valued-added component, is not being illegally copied or pirated at the lower end of the supply chain. Without a way of protecting the software the manufacturer would be free to clone and install the product on additional hardware platforms “on the side” since the commoditized hardware is generally the lower cost (value) item making up the product.
One way of mitigating some of the above problems is to use Public key cryptography (e.g. Asymmetric Key Cryptography) that enables one to verify that a software file image, such as an operating system (OS) image, is authorized to be downloaded into a hardware device. Public key digital signature algorithms can be used for sender authentication in that digital signatures can be used to authenticate the originator of the software image. Creating a digital signature for a software image typically involves computing a modification detection code for the software image. A further computation using a mathematical algorithm is used to “sign” the code with a private-key known only to the originator of the software image. The public key that corresponds to the originator's private key is made widely available to authenticate the sender. Asymmetric Key Cryptography allows the original software developer to encrypt a software image with his own private key and send it to another user who can decrypt it using the corresponding public key resulting in a highly secure transaction. Furthermore, it provides assurance that the originator (and no other) had sent the image without the originator having to reveal his private key.
In addition to security, other issues that are important to the software developer involve the concepts of availability, safety or resilience to failure. The term “availability” is used herein to refer to the ability to distribute software or software upgrades to a large number of units in an efficient and cost effective manner. For example, there is a need for the company doing the primary assembly work on the computer hardware to install or upgrade software on perhaps tens of thousands (or more) production units without requiring support personnel to attend to the units individually. The cost of the labor required for individual attention in this case would be prohibitive, not to mention experiencing a high recurring cost each time an upgrade is required or when there is a software or hardware malfunction. Moreover, if the product is deployed in the field in a remote location the cost of sending support staff to service it would be very high. Thus, there is a need for making the software installations or upgrades “available” in a secure manner to multitudes of units without requiring significant amounts of labor.
The concept of “resilience to failure” is used herein to refer to the ability of the units to recover from a catastrophic software failure. For example, there is a need for the ability to cope with a situation where software hangs from e.g. code bugs or corrupt data. A suitable mechanism is required that would enable the unit to recover and begin operating again while the unit is operating in the field, preferably without the need of significant labor by service personnel.
U.S. Patent Pub. No. 2005/0138414 to Zimmer et al. presents a method for storing boot options and integrity information on a portable token for use in a pre-operating system (pre-boot) environment. Upon booting the computer system validates an OS image using a token prior to it being loaded for execution. [IS THIS CORRECT?] The token is intended to be a tamper-proof media such as a smartcard or read-only CD which is provided to an authorized person to insert into the computer to validate the OS image. The token, inserted during the pre-boot phase, contains a binary object containing a public-key for corroborating the integrity of an OS image that is loaded from a local mass storage disk or loaded from the network. In addition, a personal identification number (PIN) and/or a biometric sensor may be employed along with the token for enhanced security.
Although the procedure described in Zimmer was developed to provide a high security mechanism for validating OS images by way of a portable personal token, it does not address the issue “availability” in the sense that validations on computer systems en masse are not suitable when using personalized tokens. This is especially true if additional security measures such as PIN codes or biometrics are required to be input by the token holder. The method inherently elicits a tradeoff between high security and high availability since it requires the presence of the token holder for the boot phase for software installations and upgrades. Furthermore, there is no verification on the token itself to verify that it is secure at the time of insertion. This leaves open the possibility that the token itself could be tampered with and rendered ineffective. The method is confined to the pre-boot environment which means that the BIOS, residing in read-only memory is the first program to run upon initialization, typically performs some relatively simple initial system checks. The BIOS contains only a few kilobytes of code and thus is not able to execute the more complex types of security policies that can be run in the post-boot environment.
The BIOS performs some initial system checks on the system and contains only a few kilobytes of code thus it has relatively limited capabilities for enabling more complex types of security policies.
In view of the foregoing, it is desirable to provide a method and system that provides control throughout the production chain that in a way that provides security of software with high availability and resilience to failure in an efficient and cost effective manner.